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Abstract. Flow-sensitive analysis for information-flow control (IFC) al¬ 
lows data structures to have mutable security labels, i.e., labels that can 
change over the course of the computation. This feature is often used 
to boost the permissiveness of the IFC monitor, by rejecting fewer runs 
of programs, and to reduce the burden of explicit label annotations. 
However, adding flow-sensitive constructs (e.g., references or files) to a 
dynamic IFC system is subtle and may also introduce high-bandwidth 
covert channels. In this work, we extend LIO—a language-based floating- 
label system—with flow-sensitive references. The key insight to safely 
manipulating the label of a reference is to not only consider the label on 
the data stored in the reference, i.e., the reference label, but also the label 
on the reference label itself. Taking this into consideration, we provide an 
upgrade primitive that can be used to change the label of a reference in 
a safe manner. We additionally provide a mechanism for automatic up¬ 
grades to eliminate the burden of determining when a reference should be 
upgraded. This approach naturally extends to a concurrent setting, which 
has not been previously considered by dynamic flow-sensitive systems. 
For both our sequential and concurrent calculi we prove non-interference 
by embedding the flow-sensitive system into the original, flow-insensitive 
LIO calculus—a surprising result on its own. 


1 Introduction 

Modern software systems are composed of many complex components that han¬ 
dle sensitive data. In many cases (e.g., mobile and web applications) these dis¬ 
parate components are provided by different authors, of varying trustworthi¬ 
ness. Unfortunately, because today’s software development tools do not provide 
a means for protecting sensitive data from untrusted code, data theft and cor¬ 
ruption is prevalent. 

Information-flow control (IFC) is a promising approach to security that pro¬ 
vides data confidentiality and integrity in the presence of untrusted code. At a 
high level, IFC tracks and controls the flow of information through a system ac¬ 
cording to a security policy, usually non-interference 0 . Non-interference states 
that public events should not depend on sensitive data and dually, trusted data 
should not be affected by untrusted events. Hence, with IFC, the program is 
guaranteed to preserve data confidentiality and integrity, even when composed 


of untrusted components. Indeed, this appealing guarantee has recently led to 
significant research and development efforts that use IFC to secure web applica¬ 
tions (e.g., 13 H3- E3 ) and mobile platforms (e.g., 11, 20j|). 

To ensure data conhdentiality and integrity, these dynamic IFC systems as¬ 
sociate security labels with data and monitor where such data can flow n@. 
In this paper, we use the labels H and L, to respectively denote secret and public 
data, and ensure that information cannot flow from a secret entity into a public 
one, i.e., the labels are ordered such that L C H and H %. L. In general, 
the partial order C (label check) is used to govern the allowed flows. We re¬ 
mark that our results apply to arbitrary lattices that may also express integrity 
21113 , se the two-point lattice for simplicity of exposition. 


concerns 


One of the facets of IFC analysis lies in how such labels, when associated 
with objects, are treated 0 . Specifically, some IFC systems (e.g., fjj. ilolfl8l l2ll 
35, H 441) treat labels on objects as immutable and do not allow for changes 


over the lifetime of the program, i.e., labels of objects are flow-insensitive. In 
contrast, other systems (e.g., [2, 3|, 43]) are flow-sensitive , i.e., they allow object 
labels to change, in certain conditions, according to the sensitivity of the data 
that is stored in the object. In general, these flow-sensitive systems are more 
permissive, i.e., they allow programs that flow-insensitive monitors would reject. 

Consider, for instance, a web application that writes to a labeled log while 
servicing user requests. If the label of the log is L, a flow-insensitive IFC monitor 
would disallow writing any sensitive data (e.g., error messages containing user- 
supplied data) to the log, since this would constitute a leak. However, in a 
flow-sensitive system, the label of the log can change (to H), as to accommodate 
the kinds of data being written to the log. For many applications, allowing labels 
to change in such a way is very desirable—it alleviates the burden of having to 
a-priori determine the precise labels of objects (e.g., the log). 

Unfortunately, naively introducing flow- 
sensitive objects to a dynamic IFC system 
can turn label changes into a covert chan¬ 
nel 31). Consider the code fragment of Fig¬ 
ure [T] where references l and h are respectively 
labeled L and H. By naively allowing arbi¬ 
trary label changes—even if the new label is 
more restricting—we can leak the contents of 
h into l. In particular, suppose that the tem¬ 
porary variable tmp is initially labeled L. If 
the value stored in h is True, then in the first 

conditional we assign True into tmp and raise its label to H, reflecting the fact 
that the branch condition depends on sensitive data. Since the tmp is True, the 
branch condition for the second conditional is False and thus the value and label 
of l are left intact, i.e., True at L. However, if h is False, then the value and label 
of tmp do not change—the first assignment is not executed. Instead, the second 
assignment, which sets l to False, is performed; since the label of the branch 
condition is L, the label of l remains L. Note that in both cases the label of l 


l := True 

tmp := False 

if h then tmp := True 

if -1 tmp then l := False 


Fig. 1: Flow-sensitive attack 














stays L, but the value of l is the same as the secret h. (Hence why label change 
is considered a covert channel.) In systems such as LIO and Breeze, which allow 
labels to be inspected, this attack can be further simplified by simply checking 
the label of tmp after the first assignment- if the secret is true then the label 
will be H, otherwise it will be L. 


This attack is not new, and, to ensure that the covert channel is not intro¬ 
duced when adding flow-sensitive references in such a way, several solutions have 
already been proposed. These solutions fall into roughly three categories. First, 
the IFC monitor can incorporate static information to ensure that such leaks are 
disallowed 3l|. Second, the IFC monitor can forbid certain label changes, de¬ 
pending on the context (e.g., the program counter (pc) label |33|). For instance, 
the no-sensitive upgrades policy disallows raising the label of a public reference 
in a sensitive context (e.g., when a branch condition is H ) El} ■ And, third, 
the monitor can disallow branches that depend on certain variables, for which 
the label was mutated, as done by the permissive upgrades policy [1] ■ 


In this paper, we take a fresh perspective on flow-sensitivity in the context 
of coarse-grained floating-label systems, in particular, the LIO IFC system [ 3 ^, 
lrj |. LIO brings ideas from IFC Operating Systems- notably, HiStar j3|- into 
a language-based setting. In particular, LIO takes an OS-like coarse-grained 
approach by associating a single “current” floating-label with a computation 
(and everything in scope), instead of heterogeneously labeling every variable, 
as typically done by language-based systems (e.g., [27j, |34j). This floating-label 
is raised (e.g., from L to H) to accommodate reading sensitive data and thus 
serves as a form of “taint” reflecting the sensitive of data in context, i.e., LIO is 
flow-sensitive in the current label. (This can be seen as raising the pc in more 
traditional language-based systems.) In turn, the LIO monitor uses the “current” 
label to restrict where the computation can write (e.g., once the current label is 
raised to H, it can no longer write to references labeled L). However, like other 
IFC systems, LIO is flow-insensitive in object labels. 


This work extends the LIO IFC system, both the sequential and concurrent 
versions, to incorporate flow-sensitive references. A key insight of this work is to 
consider labels of references as being composed of two elements: the reference 
label describing the confidentiality (integrity) of the stored value, and another 
label, called the label on the label, which describes the confidentiality (integrity) 
of the reference label itself. Our monitor, then only forbids changing a label of 
a reference if the label on the label is below the current floating-label. Inspired 
by 0 , we add a primitive for safely and explicitly upgrading labels. This boosts 
the permissiveness of LIO, and, for instance, allows programs, such at the logging 
web application described above, which would otherwise be rejected by the IFC 
monitor. 


To reduce the burden of introducing upgrade annotations, our calculus pro¬ 
vides a means for automatically upgrading references for which the computation 
is about to “lose” write access, i.e., before tainting the computation by raising 
the current label, we first upgrade all the references whose labels are below the 
(new) current label. While secure, this feature facilitates a form of label creep , 




wherein all flow-sensitive references might end up with labels that are “too high.” 
To further address this, we propose a block-structured primitive which only up¬ 
grades the labels of declared flow-sensitive references, while disallowing writes 
to undeclared ones. 

By taking a fresh perspective on flow-sensitivity, we also show that our 
flow-sensitive extension can be entirely encoded using existing flow-insensitive 
constructs—the key insight is to explicitly model flow-sensitive values as nested 
flow-insensitive labeled references. In the context of LIO, this encoding has the 
added benefit of allowing us to prove non-interference by simply invoking pre¬ 
vious results. Equally important, the sequential semantics for LIO with flow- 
sensitive references directly extend to the concurrent setting. 

The contributions of this paper are as follows: 


— We extend LIO to incorporate flow-sensitive objects, with a focus on ref¬ 
erences. Specifically, we introduce two explicit primitives to safely raise 
(upgrade) or downgrade (downgrade) the security label of references. This 
extension not only increases LIO’s permissiveness, but also provides a means 
for safely combining flow-insensitive and flow-sensitive references. 

— We present a uniform treatment for flow-insensitive and flow-sensitive refer¬ 
ences in both sequential and concurrent settings. To the best of our knowl¬ 
edge, we are the first to analyze the challenges of purely dynamic monitors 
with flow-sensitive references in the presence of concurrency. 

— A non-interference proof for the different calculi that leverages the encoding 
of flow-sensitive references using flow-insensitive constructs. 


The novel aspect of this article, with respect to its conference version Q, 
is the extension of our formal results to consider a downgrade primitive that 
further boosts permissiveness. Additionally, we compare our approach with no- 
sensitive-upgrade [43| and permissive-upgrade Q—two known policies for label 
changes. 

We remark that while our development focuses on LIO, we believe that 
our results generalize to other sequential and concurrent floating-label systems 

(e. g ., HE Ea IH SI)- 


The rest of the paper is organized as follows. Section [5] provides an intro¬ 
duction to LIO and its formalization. Section [3] presents our flow-sensitivity 
extensions and enforcement mechanism. Section [4] extends this approach to the 
concurrent setting. Section [5] presents the embedding of our enforcement using 
flow-insensitive constructs, from which our formal security guarantees follow. We 
discuss related work in Section [7] and conclude in Section [8] 


2 Introduction to LIO 

LIO is a language-level IFC system, implemented as a library in Haskell. The 
library provides a new monad , LIO , atop which programmers implement com¬ 
putations, which may use the LIO API to perform side effects (e.g., mutate a 
reference or write to a file). 






Values v 
Terms f 


::= True \ False | () | A x.t \ i \ LIO TCB t 
::= v | x | t t | fix t | if t then t else t 
| t ® t | return t \ t >= t | getLabel 
Types r ::= Bool | () | r —» r | £ | LIO t 
Ops^ <g> :::= U | fl |C 


Fig. 2: Syntactic categories for base A^ 10 . 


The LIO monad implements a purely dynamic execution monitor. Specifi¬ 
cally, LIO encapsulates the state necessary to enforce IFC for the computation 
under evaluation. Part of this state is the current (floating) label. Intuitively, the 
current label serves a role similar to the program counter (pc) of more-traditional 
IFC systems (e.g., 134]): it is used to restrict the current computation from per¬ 


forming side-effects that may compromise the confidentiality or integrity of data 
(e.g., by restricting where the current computation may write). 

To soundly reason about IFC, every piece of data must be labeled, including 
literals, terms, and labels themselves. However and different from most language- 
based systems (e.g., 18, [2(| 341) where every value is explicitly labeled, LIO 


takes a coarse-grained approach and uses the current label to protect all values 
in scope. As in IFC operating systems 10|, 441, in LIO, the current label Z cur is 


the label on all the non-explicitly labeled values in the context of a computation. 

To allow for computations on resistive data, LIO raises the current label to 
protect newly read data. That is, the current label is raised to “float” above the 
labels of all the objects read by the current computation. Raising the current 
label allows computations to flexibly read data, at the cost of being more limited 
in where they can subsequently write. Concretely, a computation with current 
label / C ur can read data labeled U by raising its current label to /' ur = Z cur U Id , 
but can thereafter only write to entities labeled l e if /' ur C l e . Hence, for 
example, a public LIO computation can read secret data by first raising Z cur from 
L to H. Importantly, however, the new current label prevents the computation 
from subsequently writing to public entities. 


2.1 A), 10 : A coarse-grained IFC calculus 

We give the precise semantics for LIO by extending the simply-typed, call-by- 
name A-calculus; we call this extended IFC calculus A^ 10 . The formal syntax of 
the core X“° calculus, parametric in the label type £, is given in Fig. [2] Syntactic 
categories v, t , and r represent values, terms, and types, respectively. Values 
include standard primitives (Booleans, unit, and A-abstractions) and terminals 
corresponding to labels (£) and monadic values (LIO TCB We note that values 
of the form LIO TCB t denote computations subject to security checks. (In fact, 

3 We restrict our formalization to computations implemented in the LIO monad and 
only consider Haskell features relevant to IFC, similar to the presentation of LIO 
in [!§]. 








E ::= E t \ fix E | if E then t else t\E®t\v®E 
E ::= [] | E | E»( 


getLabel 

E ~ (/cur, ■■•) 

(A7|E [getLabel]) —> (E|E [return / CU r]) 

Fig. 4: Evaluation contexts and getLabel reduction rule. 

security checks are only applied to such values.) Terms are composed of stan¬ 
dard constructs (values, variables x, function application, the fix operator, and 
conditionals), terminals corresponding to label operations (/(g)/, where U is the 
join, n is the meet, and C is the partial-order on labels), standard monadic op¬ 
erators (return / and / >*= /), and getLabel, a term for inspecting the current 
label, as further explained below. We do not consider terms annotated with • TCB 
as part of the surface syntax, i.e., such syntax nodes are not made available to 
programmers and are solely used internally in our semantic description. Types 
consist of Booleans, unit, function types, labels, and LIO computations; since 
the A^ 10 type system is standard, we do not discuss it further. 

We include monadic terms in our calculus since (in Haskell) monads dic¬ 
tate the evaluation order of a program and encapsulate all side-effects, including 
I/O [ill [4p|: LIO leverages monads to precisely control what (side-effecting) op¬ 
erations the programmer is allowed to perform 
In particular, an LIO program is simply a computation 
in the LIO monad, composed from simpler monadic 
terms using return and bind. Term return / produces 
a computation which simply returns the value denoted 
by /. Term ><=, called bind , is used to sequence LIO 
computations. Specifically, term />=(Ax./') takes the 
result produced by term / and applies function Ax./' to 
it. (This operator allows computation /' to depend on 
the value produced by /.) We sometimes use Haskell’s 
do-notation to write such monadic computations. For example, the term / 

Ax. return (x + 1), which simply adds 1 to the value produced by the term /, 
can be written using do-notation as shown in Figure [3] 

A top-level X L f° computation is a configuration of the form (E\t), where / is 
the monadic term and E is the state associated with the term. As in |35j, |3f|, we 
take an imperative approach to modeling the LIO state as a separate component 
of the configuration (as opposed to being part of the term). We partially define 
the state of A), 10 to (at least) contain the current label Z cur , i.e., E = (Z cur ,...); 
here, ... denotes other parts of the state not relevant at this point. Under this 
definition, a top-level well-typed A^ 10 term has the form A, T b / : LIO r, where 
A is the store typing, and r is the usual type environment. 


at any given time. 

do x 4 — / 

return (x + 1) 

Fig. 3: do-notation 



v I Lb TCB l t 

t ::= • • • | label t t | unlabel t | labelOf t 
t ::= • • • | Labeled r 

E ::=••• | label E t | unlabel E | labelOf E 


LABEL 


E — (/cur, ••■) /cur U l 


(r|E [label l /]} —> (r|E [return ( Lb TCB l /)]) 


UNLABEL 

E = (/cur, ■ ■•) /cur — /cur U / E = (/cur, ■•■) 

(I7|E [unlabel (Lb TCB l t )]) — (AZ^E [return t]) 
labelOf 

E [labelOf (Lb TCB It)] —> E [/] 


Fig. 5: Extending base A^ 10 with labeled values. 


We use evaluation contexts in the style of Felleisen and Hieb to specify the 
reduction rules for A“° 12]. Figure [4] defines the evaluation contexts for pure 
terms ( E ) and monadic terms (E) for the base A^ 10 . The definitions are standard; 
we solely highlight that monadic terms are evaluated only at the outermost use 
of bind (E >*= t), as in Haskell. For the base A^ 10 , we also give the reduction 
rule for the monadic term getLabel, which simply retrieves the current label. 
As shown later, it is precisely this label that is used to restrict the reads/writes 
performed by the current computation. The rest of the reduction rules for the 
base calculus are straight forward and given Appendix [A] 


2.2 Labeled values 

Using / cur as the label on all terms in scope makes it trivial to deal with implicit 
flows. Branch conditions, which are simply values of type Bool , are already 
implicitly labeled with Z cur - Consequently, all the subsequent writes cannot leak 
this bit—the current label restricts all the possible writes. However, this coarse¬ 
grained labeling approach suffers from a severe restriction: a piece of code cannot, 
for example, write a public value (e.g., 42) to a public channel labeled L after 
observing secret data, even if the value is independent from the secret—once 
secret data is read, the current label is raised to H thereby “over tainting” the 
public data in scope. 

To address this limitation, LIO provides Labeled values. A Labeled value is a 
term that is explicitly protected by a label, other than the current label. Figure[5] 
shows the extension of the base A^ 10 with Labeled values. 

The label terminal is used to explicitly label a term. As rule (label) shows, 
label l t associates the supplied label l with term t by wrapping the term with 








the Lb TCB constructor. Importantly, it first asserts that the new label (l), which 
will used to protect t, is at least as restricting as the current label, i.e., l cu r C l. 

Dually, terminal unlabel unwraps explicitly labeled values. As defined in 
rule (unlabel), given a labeled value Lb TCB l f, unlabel returns the wrapped 
term t. Since the returned term is no longer explicitly labeled by l, and is instead 
protected by the current label, l cur must be at least as restricting as l. To ensure 
this, the current label is raised from l CUI to l cur LI l , capturing the fact that the 
remaining computation might depend on t. This rule highlights the fact that 
the current label always “floats” above the labels of the values observed by the 
current computation. 

The labelOf function provides a means for inspecting the label of a labeled 
value. As detailed by reduction rule (labelOf), given a labeled value Lb rcB l t, 
the function returns the label l protecting term t. This allows code to check 
the label of a labeled value before deciding to unlabel it, and thereby raising 
the current label. It it worth noting that regardless of the current label in the 
configuration, the label of a labeled value can be inspected- hence labels are 
effectively “public. ”0 

A common problem with dynamic IFC systems is label creep (33}—the rais¬ 
ing of the current label to a point where the computation can no longer do 
anything useful. To avoid label creep, LIO provides toLabeled as a way to al¬ 
low the current label to be temporarily raised during the execution of a given 
computation. We extend the terms and the pure evaluation context as t ::= 
• • • | toLabeled t t and E ::= • • • | toLabeled E t, respectively, and give the 
precise semantics for toLabeled as follows: 


toLabeled 


(E\t) — (E'\LIO T 


E — (Z C ur> •••) 

t') S' = (4 


i' c 

l cur — 


l 


E” = E k E' 


(£|E [toLabeled l t}) —> (E” |E [label l t']) 


If the current label at the point of executing toLabeled l t is l c ur , toLabeled 
evaluates t to completion ((E\t) —»•* (E'\LIO TCB t')) and restores the current 
label to Z cur , i.e., toLabeled provides a separate context in which t. is evaluated. 
(Here, the state merge function k is defined as: E x E' = E, in the next 
section we present an alternative definition.) We note that returning the result 
of evaluating t directly (e.g., as (I7|E [toLabeled l £]) —> (17" |E [£'])) would 
allow for trivial leaks; thus, toLabeled labels t' with l ((27"|E [label l t 1 ])). 
This effectively states that the result of t is protected by label /, as opposed to 
the current label (Z' ur ) at the point t completed. Importantly, this requires that 
the result not be more sensitive than l, i.e., l' CUT C l. 


4 Since labeled values can be nested, this only applies to the labels of top-level labeled 
values. Indeed, even these labels are not public—they are protected by the current 
label. However, since code can always observe objects labeled at the current label, 
this is akin to being public. 




V 

t 


Ref™ l a 

newRef s t t | writeRef, t t | readRef s t 
labelOf, t | copyRef t t 
T ::=••• | Ref s t 

E ::= • • • | newRef s E t | writeRef s E t | readRef s E 
| labelOfs E | copyRef E t | copyRef v E 


newRef-fi 

E — (/cur; /Xfi, ■•■) /cur E / /Cpi ~ Pfi [o, I ^ Lb It ] E — (/cur, Pfi, ■■■) 

(I7|E [newRef F i l £]) —> (AAlE [return (Ref™ l a)]) 
readRef-fi 

E — (Icun /^FI5 •■•) 

<r|E [readRefp, (Ref™ l a)]) —> (r|E [unlabel fj, F1 (a)]) 
writeRef-fi 

E — (/cur , /^FI5 ■• •) /cur E / Mfi — /2 FI [ C I ^ Z/Z? I /] E — (/cur ; /^FI, •■•) 

(I7|E [writeRefpi (Ref™ / a) £]} —>■ (-S^E [return ()]} 
labelOf-fi 


fresh (c 


E [labelOfp: (Ref™ l a)]) — >• E [/] 


copyRef 

E — (/cur 3 PFI 3 •■•) /l C /2 /cur E 

Lb TCB /i m = ^ipi (ai) Mfi = Pfi [a2 i-t Z/6 TCB ^i] E' — (l c ur ,ft„ •■■) 
(-E1E [copyRef (Ref™ k ai) (Ref™ h 02 )]) — £ (A^'lE [return ()]) 


Fig. 6: Extending A^ 10 with references. 


2.3 Labeled references 


To complete the description of LIO, we extend the A) 10 calculus with mutable, 
flow-insensitive references. Conceptually, flow-insensitive references are simply 
mutable Labeled values. Like labeled values, the label of a reference is immutable 
and serves to protect the underlying term. The immutable label makes the se¬ 
mantics straightforward: writing a term to a reference amounts to ensuring that 
the reference label is as restrictive as the current label, i.e., the reference label 
must be above the current label; reading from a reference taints the current label 
with the reference label. 

The syntactic extensions to our calculus are shown in Figure[G] We use meta¬ 
variable s to distinguish flow-insensitive (FI) and flow-sensitive (FS) productions— 
the latter are described in Section [3] We also extend configurations to contain a 








reference (memory) store /u FI : S = (l c ur ,/i F i,...); Mfi maps memory addresses— 
spanned over by metavariable a —to Labeled values. 

When creating a flow-insensitive reference, newRef FI l t creates a labeled 
value that guards t with label l ( Lb TCB l t) and stores it in the memory store at a 
fresh address a (p, F i [a >->• Lb TCB It]). Subsequently, the function returns a value 
of the form f?e/ FI CB l a which simply encapsulates the reference label and address 
where the term is stored. We remark that since any references created within 
a toLabeled block may outlive the toLabeled block computation, the merge 
function used in rule (toLabeled) must also account for this, i.e. , (Z cur , /i FI , ...) k 

(^cur) /-hi: •■■) ("cud h F u 

Rule (readRef-Fi) gives the semantics for reading a labeled reference; read¬ 
ing the term stored at address a simply amounts to unlabeling the value /i (a) 
stored at the underlying address (unlabel /r FI (a)). 

Terminal writeRef FI is used to update the memory store with a new term. 
Note that writeRef FI leaves the label of the reference intact , i.e., the label of a 
flow-insensitive reference is never changed, but, as rule (writeRef-FI) shows in 
turn, requires the current label to be below the reference label when performing 
the write (i cur E l). 

Terminal labelOf FI has the benefit of allowing code to always inspect the 
label of a reference. 

Terminal copy Ref is to copy the contents of one reference to another, with¬ 
out inspecting the contents of either reference. As given by rule (copyRef), 
the function copies the contents of a labeled reference into another one, as long 
as the source-reference label (h ) flows to the target-reference label (fc) and the 
usual condition for writing to an entity with label I 2 also holds (Z cur E h)- Since 
the computation does not read the source reference, the current label remains 
unchanged. We remarks that while copyRef can be encoded using toLabeled, 
we introduce copyRef explicitly since the use of toLabeled is prohibited in 
concurrent settings and our results rely on such a feature in both contexts (see 
Section [5J , 


3 Flow-sensitivity extensions 


The flow-insensitive references described in the previous section are inflexible. 
Consider, for example, an application that uses a reference as a log. Since the log 
may contain sensitive information, it is important that the reference be labeled. 
Equally important is to be able to read the log at any point in the program to, for 
instance, save it to a file. Although labeling the reference with the top element 
in the security lattice (T) would always allow writes to the log, and toLabeled 
can be used to read the log and then write it to a file, this is unsatisfactory: it 
assumes the existence of a top element, which in some practical IFC systems, 
including HiStar 44] and Hails 14J, does not exist. Moreover, it almost always 
over-approximates the sensitivity of the log. Hence, for example, a computation 
that never reads sensitive data, yet wishes to read the log content as to send error 
message to a user over the network (e.g., as done in a web application) cannot 




leakRef :: Ref FS Bool —» LIO Bool 
leakRef href = do 
tmp «— newRef L () 
toLabeled H $ do h readRef href 

when h $ writeRef tmp () 
return $ labelOf tmp = H 


Fig. 7: Attack on LIO with naive treatment of flow-sensitive references. We omit 
subscripts for clarity. 

do so—LIO prevents the computation from reading the log, which results in the 
computation getting tainted by T, and subsequently writing to the network[f|lt 
is clear that even for such a simple use case, having references with labels that 
vary according to the sensitivity of what is stored in the reference is useful. 

However, naively implementing flow-sensitive references can effectively intro¬ 
duce label changes as a covert channel. Suppose that we allow for the label of 
a reference to be raised to the current label at the time of the writeRef. So, 
for example, if the label of our log reference is L and the computation has read 
sensitive data (such that the current label is H), subsequently writing to the log 
will raise the label of the reference to H. Unfortunately, while this may appear 
safe, as previously shown in HIE), the approach is unsound. 

The code fragment in Figure [7] defines a function, leakRef , that can be used 
to leak the contents of a reference by leveraging the newly introduced covert 
channel: the label of references. (In this and future examples we use function 
when to denote an if statement without the else branch and (S) as lightweight 
notation for function application, i.e., f$x is the same as / (x).) To illustrate an 
attack, suppose that the current label is public (L) and leakRef is called with 
a secret (H) reference (href). leakRef first creates a public reference tmp and, 
then, within the toLabeled block—which is used to ensure that the current 
label remains L —the label of this reference is changed to H if the secret stored 
in href is True , and left intact (L) if the secret is False. The value stored in href 
is revealed by simply inspecting the label of the tmp reference |f| 

Fundamentally, the label protecting the label of an object, such as a reference 
or labeled value, is the current label l cur at the time of creation. Hence, to modify 
the label of the object within some context (e.g., toLabeled block) wherein the 
current label is Z' ur , it must be the case that l' cnr C / cur , i.e., we must be able to 
write data at sensitivity level Z' ur into an entity—the label of the object—labeled 
/ CU r- This restriction is especially important if / cur C Zc Ur and we can restore 
the current label from Z' ur to Z cur , since a leak would then be observable within 
the program itself. In the case where the label of the object is immutable, as is 
the case for flow-insensitive references (and labeled values), this is not a concern: 

5 Here, as in most IFC systems, we assume the network is public. 

6 The use of labelOf is not fundamental to this attack and in Appendix [B] we show 
an alternative attack that does not rely on such label inspection. 



even if the current label is raised to l' cur and then restored to Z cur , we do not 
learn any information more sensitive than Z cur —the label of the label at the time 
of creation -by inspecting the label of the reference (or value): the label has not 
changed! 

Thus, to extend LIO with flow-sensitive references, we must account for the 
label on the label of the reference at the time of creation, Z cur . (This label is, 
however, immutable.) In turn, when changing the label of the reference, we must 
ensure that no data from the context at the time of the change, whose label is 
Z' ur , is leaked into the label of the reference by ensuring that l' CUI E l c ur , i.e., 
we can write data labeled Z(, ur into the label that is labeled Z cur . 

Formally, we extend the A)> 10 syntax and reduction rules as shown in Figure [8} 
we call this calculus A^'° s . To create a flow-sensitive reference newRef FS l t 
creates a labeled value that guards t with label l ( Lb TCB l t). Since we wish to 
allow programmers to modify the label l of the reference, we additionally store 
the label on /, i.e., the current label Z cur , by simply labeling the already-guarded 
term (/z FS = /x FS [a i-a Lb TCB l c ur ( Lb TCB l f)]), as shown in rule (newRef-fs). 
Primitive newRef FS returns a i?e/ FS CB a which simply encapsulates the fresh 
reference address where the doubly-labeled term is stored. Different from the 
constructor -Re/ FI CB , the constructor Ref Jg B does not encapsulate the label of 
the reference. This is precisely because the label of a flow-sensitive reference is 
mutable and must be looked up in the store. As given by rule (labelOf-fs), 
labelOf FS returns the label of the reference after raising the current label (with 
unlabel) to account for the fact that the label of the reference l' is a value at 
sensitivity level l , i.e., we raise the current label to the join of the current label 
and the label on the label. 

The rule for reading flow-sensitive references is standard. As given by rule 
(readREf-FS), readRef FS simply raises the current label to the join of the 
reference label and label on the reference label (l L! I') and returns the protected 
value. This reflects the fact that the computation is observing both data at level 
l (the label on the reference) and l 1 (the actual term). 

The rule for writing flow-sensitive references deserves more attention. 
First, writeRef FS as given by rule (writeRef- 
Fs), ensures that the current computation can 
write to the reference by checking that Z cur C 
(Z U l’). We impose this condition instead of 
the two conditions Z CU r E Z and Z cur E l'~ 
which respectively check that the current com¬ 
putation can modify both, the label of the 
reference, and the reference itself—since it is 
more permissive, yet still safe. When impos¬ 
ing the two conditions independently, certain 
programs, such as the one given in Figure [9l 
would fail. In this program, we first create a flow-sensitive reference labeled H 
when the current label is L (and thus the label on H is L). Then, we raise the 
label by reading from the reference. Finally, we attempt to write to the reference. 


do r •<— newRef FS H () 
readRef FS r 
writeRef FS r () 

Fig. 9: Permissiveness test. 


v | Ref™ t 

t ::=••• | upgrade FS t t | ft' | downgrade FS t t 
E ::= ■ ■ ■ | upgrade FS E t | upgrade FS v E 

| downgrade FS E t | downgrade FS v E 


newRef-fs 


E — (Icuri /tel, /tes) Icut E ^ 

fresh(a) /tes — /tes [^ 1 ^ Lb Icut (Lb l /)] E — (/cur?/tei,/tes) 


(I7|E [newRefps l t}) —>■ (X'^E [return (Ref™ ffl )]) 
readRef-fs 

E = (Icut, /ta, /tes) /tes (a) = Lb™ l (Lb™ l't ) l" = l U l' 
<r|E [readRefps (Ref™ a)]) — > (r|E [unlabel (Lb™ l” /)]} 


writeRef-fs 

E — (Icut, /tel /tes) /tes ( a ) ~ Lb l (Lb 
Icut C (I U l') /4s = /tes [ a FA Lb™ l (Lb™ l' t)] 


l' t') 

E = (Icut , /tei, /tes) 


(I7IE [writeRefps (-Re/ FS CB a) t ]} — > (X^E [return ()]) 


writeRef-fs-fail 

E = (Icut, /te, /tes) /tes (ffl) = Lb™ l (Lb™ l! t') 1 C ut % (l U l') 

(X|E [writeRef PS (Ref™ a) /]) —> <X'|E [unlabel (L6 TCB l ft)]) 


labelOf-fs 

£ = (Eur,/tei,/tes) /tes (a) = i6 TCB l (Lb™ l't) 

<X|E [labelOf FS (Ref™ a)]) — > (£|E [unlabel (Lb™ l l')}} 


upgradeRef 

E = (Icut, /tei, /tes) /tes (a) = Lb™ l (Lb™ l" v) 

Icut E l /4a = /tes [a FA h& TCB f (L6 TCB (/" U /') V )] E' = (1 C ut , /tel, /tes) 
(-£|E [upgrade PS (Ref™ a) /']) — > (X'|E [return ()]) 


downgradeRef 


E = (/ C ur, /tei, /tes) /tes (a) = Lb™ l (Lb™ l" v) l c ur E Z 

/4s = /^FS [q FA Lb TCB i (Lb™ (i u (z" n /')) ft)] x' = (z cur ,/tei,/4s) 

(X|E [downgrade FS (Ref™ a) l']) —> (X^E [return ()]) 


Fig. 8: A“° s : extension of A“° with flow-sensitive references. 











Under our semantics, this program behaves as expected; however, when impos¬ 
ing the two conditions independently, the write fails—the current label does not 
flow to the label on the label of the reference. 

Another case for writeRef FS which we must handle is when current label 
does not flow to the join of the reference label, i.e., l cul - % I U and the write 
is disallowed. If the semantics simply got stuck, the current label (at the point of 
the stuck term) would not reflect the fact that the success of applying such rule 
depends on the label l', which is itself protected by l. Indeed, this might lead to 
information leaks and we thus provide an explicit rule, (writeref-fs-FAIl), for 
this failure case that first raises the current label (via unlabel) to l and then 
diverges; in the rule, fi represents a divergent term for which we do not provide 
a reduction rule. 

Note that writeRef FS does not modify the label of the reference. This is, 
in part, because we wish to keep the difference between flow-insensitive and 
flow-sensitive references as small as possible. Instead, we provide upgrade FS 
precisely for this purpose; this primitive is used to raise the label of a reference. 
Rule (upgradeRef) is straight forward—it simply ensures that the current 
computation can modify the label of the reference by checking that the current 
label flows to the label on the label (Z cur C l). Similarly, downgrade FS is used 
to lower the label of the reference, destroying its contents, i.e., replacing its value 
with j)\ Rules (upgradeRef) and (downgradeRef) are analogous; the main 
difference is that the former uses the join operation to combine the old and new 
labels (/" U /'), whereas the latter uses the meet operation (l" n l'). The 
downgrade FS primitive is useful when one wishes to store information that is 
less sensitive into a reference. Both upgrade FS and downgrade FS highlight that 
it is safe to raise or lower the label of a flow-sensitive reference, if that the label 
on the label still flows to the final label in the nested Lb TCB structure. 

3.1 Automatic upgrades 

We can use A)) FS to implement various applications that rely on flow-sensitive 
references, even those that rely on policies such as the popular no-sensitive up¬ 
grades Using A“° s , we can also safely implement our logging application 
using a flow-sensitive reference. Unfortunately, our system (and others like it) 
requires that we insert upgrades before we raise the current label so that it is 
possible to write references in a more-sensitive context, e.g., to modify a public 
reference after reading a secret. In the case of the logging example, we would 
need to upgrade the label before reading any sensitive data, if we later wish to 
write to the log. 

We provide an extension to A^ 1 FS that can be used to automatically upgrade 
references. This extension, called A^ 1 FS+AU , is given in FigureHUl Intuitively, when¬ 
ever the current label is about to be raised, we first upgrade all the references in 
the /i FS store and then raise the current label. Rule (upgradeStore) upgrades 
every reference in the flow-sensitive store /x FS by executing ti fa t n , 

where t t = upgrade FS (Re/ F g B Oj) l. Term t t' is similar to bind except that 
it discards the result produced by t. Since unlabel is the only function that 


upgradeStore 


A= — (/cur: P’ FI) p fs) 

Mps = {“i pa «i,...,On. A fc) ti = upgrade FS (iJe/Js™ Oi) Z, i = 1,..., n 
(IZ|E [upgradeStore FS l]) —► (i7|E [Zi S> ... >• t n ]) 


UNLABEL-AU 


(X'|upgradeStore I 


A= — (/cur- /A[. Pfs ) ^cur — Zc 

s Zcur) -(Zcur, Mfi, Mfs IT-ZO 


U l 


0) A/ — (Zcurr pFli Mfs) 


(I7|E [unlabel (Lb TCB l Z)]) —>■ (U^E [return Z]} 


Fig. 10: A^° s+au : Extending A^'° s with auto-upgrades. 


raises the current label, we augment the (unlabel) rule with (UNLABEL-AU), 
given in Figure [TUI This ensures that as the computation progresses it does 
not “lose” write access to its references. Returning to our logging example, with 
auto-upgrades the reference used as the log never needs to be explicitly upgraded 
and can always be written to—an interface expected of a log. 

Recall that toLabeled is used to avoid label creep by allowing code to only 
temporarily raise the current label. Unfortunately, with auto-upgrades, when 
the current label gets raised within a toLabeled block, the upgrades of the 
flow-sensitive references remain even after the current label is restored. Thus, 
reading from any flow-sensitive reference after the toLabeled block will raise 
the current label to (at least) the current label at the end of the toLabeled 
block (since all references are upgraded every time the current label gets raised). 
This can be used to carry out a poison pill-\\ke attack [18]. wherein the (usually 
untrusted) computation executing within the toLabeled block will render the 
outer computation useless via label creep. (We note that this attack is possible 
in A^° s without the auto-upgrade, but requires the attacker to manually insert 
all the upgrades.) 

To address this issue, we extend A^'° s (and A“° s+au ) with withRefs FS v Z, 
which takes a bag (strict heterogeneous list) v of references and a computation 
Z, and executes Z in a configuration where the flow-sensitive reference store only 
contains the subset of references v (and any nested references). This extension 
and type rule (Type-WIThRef), which ensures that a term cannot access a 
reference outside its store, are shown in Figure [TTi 

A bag is either empty £ 7 = 7 x 7 , or it may contain a set of references of (poten¬ 
tially) distinct types v^T.. Rules (withRefs-Ctx) and (withRefs-Done) pre¬ 
cisely define the semantics of this new primitive, where the meta-level function 
addrs(-) converts a bag of references to a set of their corresponding addresses, 
addrs ~ l (•) performs the inverse conversion, and k is used to merge the stores, 
giving preferences to the left-hand-side store, i.e., when there is a discrepancy 
on a stored value between both stores, it chooses the one appearing on the left- 
hand-side. The function addrs^(-) computes the closure of addrs{-) under store 
p, so as to include the addresses of arbitrarily-nested references. Note that if we 
did not include these addresses in the restricted store p' FS , evaluation might get 
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withRefs F s t t 


E 


E, t,... \ v,E,t,... 


withRefs F s E t 

A 0 

addrs(RefJf B ai, RefJs B aa,...) = {ai, 02 ,...} 


addrs(e -—) 


addrs +=0 

addrSp(v i, V2,...) = U {addrs+(vi), addrs^fa), ■■■} 
addrs^(RefJg B a) = {a} U addrs^(fi (a)) 
addrs^(v) = 0 


withRefs-Ctx 

•E = (icurj/ipi^ps) Mfs = {a !->• Mfs (a) | a € dom/x FS n (oddrs+ ps ((;))} 

(^cur ? [£]) >• (l 

cur 5 M fi,Mfs|E [«']) 

E" = (Z' ur , Pfi, A^fs * Mfs) ?/ = addrs^ 1 (dom /i" s ) 

(A7|E [withRefsps t; £]) — > (E^E [withRefs FS v t 7 ]} 


withRefs-Done 


(^7|E [withRefsps v i/]) —*• (S|E [?/]) 
Type-withRef 

A' = {a t-» A (a) | a £ dom A n (addrs(v))} 
A', Eh v : Ref ss n,... A',T t ■. LIO t 

A,T\- withRefsps v t : LIO r 


Fig. 11: Extending A“° s and A)'° s+au with withRefs FS . 

stuck if the program attempted a readRef FS operation on a nested reference. 
We note that (withRefs-Ctx) is triggered until the term under evaluation is 
reduced to a value, at which point (withRefs-Done) is triggered, returning 
said value; we specify this big-step rule in terms of small-steps to facilitate the 
formalization of our concurrent calculus (see Section |4]). Aside from the model¬ 
ing of bags, the withRefs FS primitive is straightforward and mostly standard; 
indeed, the programming paradigm is similar to that already present in some 
mainstream languages (e.g., C++’s lambda closures require the programmer to 
specify the captured references). Lastly, we note that the poison pill attack can 
now be addressed by simply wrapping toLabeled with withRefs FS , which pre¬ 
vents (untrusted) code within the toLabeled block from upgrading arbitrary 
references. 


4 Concurrency 

In this section, we consider flow-sensitive references in the presence of concur¬ 
rency (e.g., a web application in which request-handling threads share a common 












log). Concretely, we extend our sequential A“° s and A“° s+au calculi with threads 
and a new terminal, forkLIO, for dynamically creating new threads, as in the 
concurrent version of LIO [3^]. Intuitively, this concurrent calculus AjS~ LI ° simply 
defines a scheduler over sequential threads, such that taking a step in the con¬ 
current calculus amounts to taking a step in a sequential thread and context 
switching to a different one. For brevity, we restrict our discussion in this sec¬ 
tion to the case where the underlying sequential calculus is A)'° S+AU , since this 
calculus extends Ay° g . 


A ::= • • • | forkLIO A | toLafeefetfTT 

forkLIO 

(£|E [forkLIO A]} f °^4 ) <r|E [return ()]) 


withRefs-Opt 

v = addrs -1 ((addrs(vi)) (~l (addrs(v 2 ))) {■S'|E [withRefs FS v A] — > (X'^E [A 7 ])) 

(A^lE [withRefsp-s Vi (withRefs PS V2 A)]> —► <^'|E [A']> 


T-step 

A/ = (Acur, A^FI, /^fs) 

(Ai’lwithRefsps v A) —> {E'\t') E' = (l' CUI , fi FI , n' FS ) v 1 = addrs ^ 1 (dom n' FS ) 

{// F I, fjy FS I (Icur , V , A) , k2 , ■ ■• } ^ {^FIl A^FS 1^2, ..., (A cur , ^ 5 t ) } 

T-stuck 


{/^FI, /^FS I (leur, V , If), A>2, ...} ^ {t^FI, A^fs)^, ...} 

T-done 

{/Tfi, A^FS I (leur, V, V ), hi, ...} > {/Tfi, /Tfs|^2, 

T-fork 

E = (1cm, Hm,Hvs) (£'|withRefs FS v A) 5 {E'\t") 

E — (l C un Mfi? Mfs) v — addvs [dom fj, F s ) A:,,.. w — (loin c , A ) 

{/Ri, A^fs I (Acur, V : A) , k.2, ... } A { A' m • A^FsIfe 5 (Icun ^ , A ), knew } 

Fig. 12: Semantics for A^ LI °, parametric in the flow-sensitivity policy, i.e., with 
and without auto-upgrade. 


Figure fl2l shows our extended concurrent calculus, A^ LI °. A concurrent pro¬ 
gram configuration has the form {/i F i,/r FS |fci, fe,...}, where /i F 1 and a*fs are re¬ 
spectively the flow-insensitive and flow-sensitive stores shared by all the threads 
hi, fo,... in the program. Since the memory stores are global, a thread k is sim¬ 
ply a tuple encapsulating the current label of the thread A cur , the term under 
evaluation A, and a bag of references v the thread may access, i.e., k = (A cur , v , A). 








The reduction rules for concurrent programs are mostly standard. Rule (T- 
STEP) specifies that if the first thread in the thread pool takes a step in A“° s+au , 
the whole concurrent program takes a step, moving the thread to the end of the 
pool. We note that the thread term t executed with its stored current label Z cur , 
and a subset of the flow-sensitive memory store, by wrapping it in withRefs FS . 
While the use of withRefs FS makes the extension straightforward, one peculiar¬ 
ity arises: since (T-STEP) always wraps the thread term t with withRefs FS , if t 
does not reduce in one step to a value, and instead reduces to a term Z', the next 
time the thread is scheduled, we will superfluously wrap withRefs FS t' with 
yet another withRefs FS —thus preventing the thread from making progress! To 
address this problem, we extend the calculus with rule (withRefs-Opt) that 
collapses nested withRefs FS blocksQ 


Rules (T-DONe) and (T-STUCK) specify that once a thread term has reduced 
to a value or got stuck, which is represented by ff, the scheduler removes it from 
the thread pool and schedules the next thread. 

As shown in Figure 1121 to allow for dynamic thread creation, we extend 
A^'° s+au ’s terms with forkLIO, and add a new reduction rule that sends an 
event to the scheduler, specifying the term to execute in a new thread^ Rule 
(T-FORk) describes the corresponding scheduler rule, triggered when a fork ( t') 
event is received. Here, we create a new thread /Cn ew whose current label l' cnr and 
partition of the store, i.e., bag of references v', is the same as that of the parent 
thread; the term evaluated in the newly created thread is provided in the event: 
t'. Subsequently, we add the new thread to the thread pool. 


The final modification in extending A«"L, A to A^ LI ° is the removal of toLabeled 
from the underlying calculus. As described in [36j, we must remove toLabeled to 
guarantee termination-sensitive non-interference. Importantly, however, forkLIO 
with synchronization primitives (e.g., flow-insensitive labeled MVars, as dis¬ 
cussed in 36]) can be used to provide functionality equivalent to that of toLabeled. 
Due to space constraints we omit synchronization primitives from A^ LI °; we only 
remark that extending Ajf uo to provide flow-sensitive labeled MVars follows in a 
straightforward way. 

Since the flow-sensitive attack in Figure Q relied on toLabeled to restore the 
current label, a natural question, given that we remove toLabeled, is whether 
we can use the naive flow-sensitive reference semantics of Section [3] for concur¬ 
rent LIO. As shown by the attack code in Figure [T3J in which we use forkLIO 
instead of toLabeled to address a potential label creep, the fundamental prob¬ 
lem remains: the label on the reference label is not protected! This precisely 
motivated our principled approach of extending A^'° s+au to a concurrent setting 
as opposed to extending concurrent LIO with flow-sensitive references. 


1 This change also requires modifying (withRefs-Ctx) to not be triggered when the 
term being evaluated is a withRefs FS term. 

8 In fact, the reduction rule for AV° s+au must be changed to account for events. 
However, since fork is the only event in our system, we treat —> as implicitly 
carrying an empty event. 




leakRef :: Ref rcB Bool -> LIO Bool 
leakRef href = do 
trap newRef L () 
forkLIO $ do h <— readRef href 

when h $ writeRef tmp () 

delay 

return $ labelOf tmp = H 


Fig. 13: Attack on concurrent LIO with naive flow-sensitive reference extension. 


5 Formal results 

In this section, we show that our flow-sensitive enforcement can be embedded into 
the flow-insensitive version of LIO. Additionally, we provide security guarantees 
in terms of non-interference definitions by reusing previous results on LIO. 


5.1 Embedding into A^ 10 

Every flow-sensitive reference with label Id created in a context where the current 
label is l 0 (and thus stored in p FS as Lb TCB l D ( Lb TCB U f)), can be represented 
by a flow-insensitive reference with label l a , whose contents are another flow- 
insensitive reference containing t and labeled Id- 

Figure [L|] gives our encoding of the flow-sensitive reference operations in 
terms of flow-insensitive references. For a given store £, we define the [—]j^ 
function, which given a term t in A^° s , produces a term in A^ 10 , expanding 
the definitions of flow-sensitive operations in terms of flow-insensitive ones. This 
function is applied homomorphically in all other cases. We use the WrapRef con¬ 
structor to mark the flow-insensitive references that are being used to represent 
flow-sensitive ones, so as to distinguish them from other flow-insensitive refer¬ 
ences. The functions wrap and unwrap are used to add and remove this bound¬ 
ary encoding. In the embedding of writeRef FS , we use toLabeled to make any 
changes to the current label (possibly caused by reading the outer reference) 
local to this operation. Inside toLabeled, the code fetches the inner reference 
(readRef FI ), and then performs the actual write of the new value. If this fails, 
the computation diverges, but, importantly, the current label was raised (with 
readRef FI ) to reflect the fact that the label on the label of the reference was 
observed. The embedding of upgrade FS relies on flow-insensitive primitives to 
implement the upgrade operation. As in writeRef FS , a toLabeled block is used 
to delimit the taint on the current label. Inside the block, the code fetches the 
inner reference (readRef FI ), which taints the current label with l', and makes a 
new reference n (newRef FI ) with the upgraded label (Z cur U (I U labelOf *)) 
and an undefined value (_L). Observe that the operation for creating the refer¬ 
ence always succeeds since its label is above the current label, i.e., Z CU r- Then, 


copyRef is used to copy the value of the original inner reference into the new 
one, n. As before, this action always succeeds because the label of the reference 
bound to i (labelOf i) is below the label of the new reference n. Finally, the 
reference n is stored in place of the original inner reference using writeRef.. 
Importantly, this instruction only succeeds when the current label at the time of 
writing, i.e., Ic U /' in Figure [TH is below or equal to V (the label of the outer 
reference), i.e., 1c U f C l'. This restrictions holds when the current label 
at the time of upgrade, i.e., Ic, is below or equal to /'—effectively encoding the 
non-sensitive upgrade policy for label changes. The embedding of downgrade FS 
follows similarly, except that the label of the new reference is computed using n 
instead of U (to achieve the downgrade), and the copyRef step is omitted, since 
the original value must be destroyed. We remark that that the mapping mimics 
the behavior described by the rules in Figure [5] 

We extend this definition naturally to convert A^'° s environments into A^ 10 

environments, by having |(/ cur , Mfi> Mfs)]fi — Gcur,/4i) w here /r FI is obtained by 
extending fi Fl with the pair of bindings di i->- Lb TCB l 0 (Refff B Id b{),bi 
(. Lb TCB Id v) (with bi being a fresh name) for each binding of the form Oi 
Lb TCB l a ( Lb TCB Id Vi) in /x FS . Note that the domains of /x FI and p FS are disjoint 
because the fresh(-) predicate that we use in the semantics is assumed to produce 
globally unique addresses. 

In order to prove that our implementation is correct with respect to the 
semantics, we show that, if we take a program with flow-sensitive operations, 
and expand those operations, replacing them by the code in Figure [Til then its 
behavior corresponds with the flow-sensitive semantics. 

Theorem 1 (Embedding A),'° s in A), 10 ). Let t be a well-typed term in A" FS . 
Then if (S\t) — {S'\v), we have ([N] FI |[t]]£) —>* and if 

{E\t) then <P?] FI |[0 —►* <[£'1^). 

Proof. See Appendix [C] 

While straight forward, this theorem highlights an important result: in floating 
label systems, flow-sensitive references can be encoded in a calculus with flow- 
insensitive references and explicitly labeled values. 

5.2 Security guarantees for A^° s , A), l0 fs + au and A|) uo 

From previous results j35j . we know that LIO satisfies termination-insensitive 
non-interference (TINI) in the sequential setting, and termination-sensitive non¬ 
interference (TSNI) in the concurrent setting. By using the embedding theorem 
we can extend these results for LIO with flow-sensitive references. 

For completeness, we now present our non-interference theorems, as straight¬ 
forward applications of the theorems in previous work. Our security results rely 
on the notion of /-equivalence for terms and configurations, which captures the 
idea of terms that cannot be distinguished by an attacker which can observe data 
at level l. A pair of terms fi, t 2 is said to be /-equivalent (written t\ < 2 ) if, 


wrap r = WrapRef r 
unwrap (WrapRef r) = r 

P?e/p S CB rJ^ our,MEI ’ MFs) = wrap (Refff B (labelOf F: p FS (r)) r) 

[newRefpsJ^; = A l t .do 
i 4— ncwR.ef'i i l t 

/ C ur 4— getLabel 

o 4— newRefpi Z cur i 

return (wrap o) 

[readRef F sj|; = Ar.readRefpi ( unwrap r) readRefpi 

[writeRefpsJn = Ar /.let o = unwrap r in do 
/cur 4— getLabel 

toLabeled (/ CU r LI (labelOf o)) $ do 
i <- ■ readRef FI o 
writeRefpi i t 

[labelOfpsjl; = Ar. 

readRefpi ( unwrap r) return.labelOf FI 

[upgrade FS ]|; = Ar l .let o = unwrap r 

l' = labelOf o in do 

Ic 4— getLabel 
toLabeled (Ic U /') $ do 
i 4— readRefpi o 
/cur 4— getLabel 

n 4— newRefpi (Z cur U (/ U labelOf i)) _L 
copyRef i n 
writeRefpi o n 

[downgrade FS ]^ = Ar /.let o = unwrap r 

l' = labelOf o in do 

Ic 4— getLabel 
toLabeled (Ic U l') $ do 
i 4— readRefpi o 
/cur 4— getLabel 

n 4— newRefpi (l CUI U (/ n labelOf i)) _L 

writeRefpi o n 

[withRefsp S v = [/lp! cur ’ MP, ’^ s) 

where 

fj,' ¥S = {a i-4 p, FS (a) | a £ dom/x FS n (addrs^ ¥S (v))} 


Fig. 14: Implementation mapping for flow-sensitive references. For all other 
terms, the function is applied homomorphically. 


after erasing all the information more sensitive than l from fa and fa , we obtain 
syntactically equivalent terms. This definition extends naturally to configura¬ 
tions. 

Intuitively, non-interference means that an attacker at level l cannot distin¬ 
guish among different runs of a program with /-equivalent initial configurations. 

Theorem 2 (TINI for A)'f s ). Consider two well-typed terms fa and fa in A"° s 
which do not contain any ■ TCB syntax nodes, such that fa fa, where l is the 
attacker observation level. Let £ be an initial environment, and let 

(£\fa) —>* (£\\v\) and ( £\fa) —>* (£ 2 ^ 2 ) 

Then, we have that (17111)1) (A72|u2). 

Proof. By expanding all the flow-sensitive operations in fa and fa using their defi¬ 
nition given in Figure ITU we get terms in A) 10 , which by TheoremGDiia s eq uivalent 
semantics. Therefore, the result follows from the X L )° TINI result of 1351 ] . 

Corollary 1 (TINI for A^'° s _|_ au ). The previous non-interference result can be 
easily extended to Aj/° s+Au . In A"° s+au , the unlabel operation triggers the au¬ 
tomatic upgrades mechanism, which performs the upgrade operation for every 
flow-sensitive reference in scope before actually raising the current label. Regard¬ 
less of how unlabel is used, we note that the resulting term (after inserting the 
necessary upgrades), is just an A)'° g term. Therefore, the main TINI result for 
Xf° s applies. 

For the concurrent result, we need a supporting lemma which states that 
the current label is always at least as sensitive as the label of every reference in 
scope. Formally, 

Lemma 1. Let t be a well-typed term in X)' LI °, £ = (l C ur,fa foMfs) be an initial 
environment, and a be the address of a flow-sensitive reference r in £, where 
/i FS (a) = Lb TCB l 0 ( Lb TCB l d v). Then, if (£\t) —>* (l' cur , p' F1 , p.' FS \t'), we have 
that l 0 C l' cur . 

Proof. Note that the result holds immediately after creating r, since the current 
label is the label on the label of r, i.e., l 0 = l CUI . It is easy to show that l 0 is 
immutable, since there are no reduction rules that modify it. Moreover, given 
that the current label is monotonic, the only way in which l a C l CUI can cease 
to hold is if r is accessed from a different thread. But in order to pass r to a 
different thread, a labeled object must be used as intermediary, and the label of 
such object would have to be at least l cur , the current label in the thread that 
created r. As a result, if we were to pass r to another thread in this way, then 
the target thread would also have to be tainted by l cu r , and the result would still 
hold. 

We now prove our non-interference theorem for A^ LI °. This result is stronger 
than TINI, since it implies that there can be no termination or internal timing 
leaks. 


Theorem 3 (TSNI for A^‘ LI °). Consider two well-typed terms fa and fa in \\ uo 
which do not contain any ■ TCB syntax nodes, such that fa fa, where l is the 
attacker observation level. Let £ = (l cur , faFi, Mfs) be an initial environment, and 
let 

{/i FI ,/z FS |(/ cur , addrs^ 1 {dom /x FS ), h}} — M\ 

Then, there exists some configuration M- 2 such that 

{g-Fi, ti F s\{lcur, addrs^ 1 (dom /Ifs), fa)} — M 2 


and M\ M 2 . 

Proof. From Lemma[l]and looking at the embeddings of writeRef FS and upgrade FS , 
we note that the first readRef FI operation in each toLabeled block will be try¬ 
ing to raise the current label to l. However, since l C l CUI , these operations will 
never effectively raise the current label. This means that using toLabeled is 
not necessary to preserve the semantics, because there is no need to restore the 
current label afterwards. As a result, and after removing toLabeled in these two 
cases, we note that the embedding produces valid concurrent A^ 10 terms (which 
does not have toLabeled). 

Finally, by expanding all the flow-sensitive operations in t\ and fa using 
their definition given in Figure ITT! we get terms in concurrent A^ 10 . Therefore, 
the result follows from the termination-sensitive non-interference of concurrent 

A)? 10 & 

The detailed proofs for the results in this section can be found in Appendix [Cl 
We lastly remark a limitation: while we preserve non-interference when embed¬ 
ding the flow-sensitive calculus in the original LIO, our embedding includes no 
synchronization to ensure atomicity of the flow-sensitive operations, so certain 
interleaving that break semantic equivalence are possible. 


5.3 Permissiveness 


In Section [7] we compare the permissiveness of our system with previous flow- 
sensitive IFC systems. Here, we solely remark that the above results imply that 
our flow-sensitive calculus is as permissive as flow-insensitive LIO. In particular, 
any flow-insensitive LIO program can be trivially converted to a flow-sensitive 
LIO program (without auto-upgrades) by using flow-sensitive references instead 
of flow-insensitive ones. Since these references would never be upgraded, they will 
behave just like their flow-insensitive counterparts. This means that all existing 
LIO programs can be run in our flow-sensitive monitor. This includes Hails 14], 


a web framework using LIO, on top of which a number of applications have 
been built (e.g., GitStaJ^], a code-hosting web platform, LearnByHackin^J 
blog/tutorial platform similar to School of Haskell, and LambdaChair [36 
EasyChair-like conference review system). 


9 

10 


www.gitstar.com 

www.learnbyhacking.org 




6 Comparison with other policies for label change 


In this section, we compare our enforcement mechanism with two policies for 
label change: no-sensitive-upgrade (originally proposed by Zdancewic 43]) and 
permissive-upgrade, a more permissive version of the former by Austin and Flana¬ 
gan HI- We introduce a simple imperative language to simplify our compar¬ 
ison with the languages implementing the aforementioned policies. This sim¬ 
ple language has variables, if-statements, a skip command that does nothing, 
and an output command that is used to produce public outputs. This lan¬ 
guage is easily implemented in A^'° s as syntactic sugar. For example, a con¬ 
ditional statement if C\ A else B is desugared to toLabeled H (do b ■*— 
unlabel C;if b then A else B). (Here, toLabeled is used to ensure that the 
current label is restored after leaving the if-statement.) 


6.1 No-sensitive-upgrade 

The no-sensitive-upgrade discipline stops execution on any attempt to change 
the label of a public variable inside a secret context. Our A“° s calculus essen¬ 
tially implements this discipline as well—see (upgradeRef) in Figure [8] The 
original presentation of no-sensitive-upgrade allows for variables with a secret 
label to be downgraded, as long as the original contents are discarded. Our A“° s 
calculus similarly allows for this with the downgrade operation. Our approach 
differs in also allowing code to explicitly upgrade a variable before entering a se¬ 
cret context, permissively allowing writes to originally-public variables in secret 
contexts. 


6.2 Permissive-upgrade 


upgrade x H 
if h 

x := True 

if x 
skip 


The permissive-upgrade policy differs from no-sensitive-upgrade in allowing code 
to change the label of a public variables in secret contexts, but subsequently dis¬ 
allowing branches on such permissively-upgraded, or “marked,” variables. When 
upgrading a public variable in a secret context, the security label of the variable 
is changed to P where L C H C P. 

In general, the permissiveness of our approach 
is incomparable with that of permissive-upgrade. 
For example, without the upgrade operation, A^'° s 
is as expressive as no-sensitive-upgrade, and thus 
less permissive than permissive-upgrade. But, with 
upgrade we can write programs in A^'° s that would 
be rejected by a permissive-upgrade monitor. Fig¬ 
ure shows an example of one such case. In the 
example, the upgrade operation is used to en¬ 
sure that reference x , which would be marked P 
by permissive-upgrade, ends up as H in all runs; 
without the upgrade, a permissive-upgrade mon¬ 
itor would reject the branch on x. By inserting 


Fig. 15: A secure program 
that A“° s accepts. 



upgrade operations in the “right” places, our approach can become more flex¬ 
ible than permissive-upgrade. 


Of course, the challenge lies in upgrading refer¬ 
ences in a permissive fashion. And automatically 
upgrading references whenever the current label 
is raised is not necessarily more permissive than 
a permissive-upgrade monitor. Indeed, the permis¬ 
siveness of permissive-upgrade and A“° s+au are also 
incomparable. 

Figure [16] shows a program that is rejected by 
permissive-upgrade but accepted by A“ fs+au . With 
permissive-upgrade, the first branch on h upgrades 
r to P, which leads to a failure when subsequently 
trying to branch x. With A^'° s+au , on the other 
hand, reference x would be upgraded to H, permissively allowing the second 
branch. 

Conversely, Figure [TT] shows a secure program that is accepted by permissive- 
upgrade but rejected by A^'° s+au . In this program, there are two variables in 
scope: x and y, both initially public. In the first secret conditional block we assign 
to y , which with permissive-upgrade only upgrades variable y to P; x remains 
L and thus the second branch is executed, producing a public output. With 
A^'fs+au’ however, unlabeling h (an operation implicit in the first conditional, 
which inspects h) auto-upgrades both x and y to H. As a result, the current 
label at the point of the output is H, causing a failure. 

One way to address the permissiveness issues of A^° S+Au is by using withRefs FS 
to delimit the scope of the upgrades. Figure IT51 shows a modified version of the 
previous example, where y is explicitly marked as the only variable that should 
be upgraded in the first branch. As a consequence, x does not get upgraded and 
the program does not fail—the output operation is allowed. More generally, if 
there is enough static information to guide the use of withRefs FS , we believe 
that A^'° s+au could match (or exceed) the permissiveness of permissive-upgrade. 


if h 

x := True 

if x 
skip 


Fig. 16: A secure program 
that permissive-upgrade 
rejects and 
accepts. 


UIO 

/ Y,fs+au 


x, y := True 

if h 

y := False 

if x 

output (1) 


x, y := False 
withRefsps ( y ) { 

if h 

y := True 

} 


Fig. 17: A secure program that 
permissive-upgrade accepts and A^'° s+au 
rejects. 


if x 

output (1) 


Fig. 18: A secure program 
permissive-upgrade and A^° s+au 
withRefsps accept. 


that 

with 


7 Related work 


The label on the label could be seen as a fixed label that dictates which principals 
can read or modify the policy (inner label) of a flow-sensitive entity. In a different 
setting, trust management frameworks have explored this idea [4j, where role- 
based rules are labeled to restrict the view on policies—the mere presence of 
certain policies could become inappropriate conduits of information. 

Several authors propose an existence security label to remove leaks due to the 
termination covert channel 29|, 30( or certain behaviors in dynamic nested data 
structures [l(| [32]. While the existence security label and the label on the label 
are structurally isomorphic, they are used for different purposes and in different 
scenarios, e.g., inspecting labels is not allowed in [161129113011321]. 

Hunt and Sands [To[ show the equivalence (modulo code transformation) be¬ 
tween flow-sensitive and flow-insensitive type-systems. Russo and Sabelfeld L 3l] 
formally pin down the challenge of mutable labels when using purely dynamic 
monitors. They prove that monitors require static analysis in order to be more 
permissive than traditional flow-sensitive type-systems. Austin and Flanagan 
propose a privatization operation to boost the permissiveness of permissive- 
upgrade. This technique has been recently generalized to arbitrary lattices [Ij. 
Moreover, the privatization operation can only enforce non-interference when 
outputs are suppressed after branching on a marked flow-sensitive reference. 
Unfortunately, none of the mentioned work consider flow-sensitive in the pres¬ 
ence of concurrency. In fact, the notion of permissive-upgrade does not easily 
generalize to the concurrent setting, as this would require tracking occurrences 
of branches across threads. 

Recently, Hritcu et al. 


18] propose a floating-label system called Breeze. 


Like LIO, Breeze allows changes in the current context label (i.e., pc) and only 
considered values with flow-insensitive labels. Given the design similarities with 
LIO 


we believe that our results could be easily adapted to Breeze. 


Hedin et al. 17] recently developed JSFlow, an IFC flow-sensitive monitor 
for JavaScript. The monitor uses the no-sensitive-upgrade label changing policy. 
To overcome some of the restrictions imposed by this discipline, the primitive 
upgrade is introduced to explicitly change labels. Our upgrade operation re¬ 
sembles that proposed by Hedin et al. Moreover, the extension to unlabel as 
described Section [3] can be seen as an automatic application of upgrade ev¬ 
ery time that the current label gets raised. Using testing, Birgisson et al. [g] 
automatically insert upgrade instructions to boost the permissiveness of no¬ 
sensitive-upgrade. We further extend this concept of (automatic) upgrades to 
a concurrent setting. 

The Operating System IFC community has also treated the mutable label 
problem in the presence of purely dynamic monitors. Specifically, IFC OSes 
such as Asbestos HiStar [44j], and Flume [2l[ distinguish between subjects 
(processes), and objects (files, sockets, etc.) such that the security labels for 
objects are immutable, while subject labels change according to the sensitivity 
of data being read. As in language-based IFC systems, changing the label of 
subjects and object can become a covert channel, if not handled appropriated. 






Hence, HiStar and Flume require that the label of a subject be done explicitly 
by the subject code. Asbestos, on the other hand, allowed (unsafe) changes to 
labels as the result of receiving messages under specific and safe conditions. Our 
work extends these concepts with a level of indirection to allow for changes in 
object labels. 


Coarse-grained IFC enforcements, similar to the ones found in IFC OS work, 
have been applied to web browsers, e.g, BFlow [42j and COWL [39| track the 
flow of information at the granularity of protection zones and context, respec¬ 
tively. Both can be understood as tracking IFC at the iframe-level granularity. 
As in LIO, an iframe’s label, i.e., a subject’s label, must be explicitly updated. 
While our techniques can be applied to COWL, BFlow does not have fine-grained 
labeled objects; hence the flow-sensitivity result is only applicable at the pro¬ 
tection zone level. By taking a more fine grained approach, the DOM-tree could 
be thought of as being composed of flow-sensitive objects, whose security labels 
change according to the dynamic behavior of the web page, as done in 32]. 

Hoare-like logics for IFC are often flow-sensitive [e.g. [ij, J28| . Different from 
dynamic approaches, these logics have the ability to observe all the execution 
paths and safely approximate label changes. As a result, no leaks due to la¬ 
bel changes are present in provably secure programs. Le Guernic et al. 22, 23| 


combine dynamic and static checks in a flow-sensitive execution monitor. For a 
flow-sensitive type-system, Foster et al. 
limits the use of variables’ 


13] propose a restrict primitive that 
aliases in a block of code. Our withRefs FS is similar 


to restrict in being used to increase the permissiveness of the analysis. 


8 Conclusions 


We presented an extension of LIO with flow-sensitive references. As in previous 
flow-sensitive work, our approach allows secure label changes using upgrade and 
downgrade operations, as a way to boost the permissiveness of the IFC sys¬ 
tem, i.e., upgrade can be used to allow for the encoding of programs that would 
otherwise be rejected by the IFC monitor. Since manually inserting upgrade 
operations can be cumbersome, we extend the calculus to automatically insert 
upgrades whenever the current label is raised, while still giving programmers fine¬ 
grained control over which references untrusted code can upgrade. Importantly, 
our approach extends to a concurrent setting. To the best of our knowledge, this 
is the first work to address the problem of flow-sensitive label changes for a con¬ 
current, dynamic IFC language. A further insight of this work was to show that, 
by leveraging nested labeled objects, both the sequential and concurrent calculi 
with flow-sensitive references can be encoded using only flow-insensitive con¬ 
structs. As a consequence, our soundness proof can be reduced to an invocation 
of previous results for LIO. 
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APP 


FIX 


E [(Ax.ti) £2] —► E [{t2 / x} ti] E [fix (\x.t)] —> E [{fix (\x.t) / x} t\ 


ifTrue 


ifFalse 


E [if True then t2 else £3 ] — > E [£2] E [if False then £2 else £3] —> E [£3] 


labelOp 


v = [£1 ® h\i 


RETURN 



(X|E [return £]) —» (I 7 |E [LIO TCB £]) 


BIND 


<X|E [{LIO tcb £i)^=£ 2 ]} 


(r|E [£ 2 £i]> 


Fig. 19: Reduction rules for standard A ^ 10 terms. 
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A Semantics for the base calculus 

The reduction rules for pure and monadic terms are given in Figure 1191 We 
define substitution { £2 / a;} £1 in the usual way: homomorphic on all operators 
and renaming bound names to avoid captures. Our label operations LI, n, and 
C rely on the label-specific implementation of these lattice operators, as used 
in the premise of rule (labelOp); we use the meta-level partial function J-Jf, 
which maps terms to values, to precisely capture this implementation detail. 

The reduction rules for pure terms are standard. For instance, in rule (ifTrue), 
when the branch has a true condition, i.e., E [if True then £2 else £ 3 ], it reduces 
to the then branch ( E [£2])- The rest are self-explanatory and we do not discuss 
them any further. 









Since all the IFC checks are performed by individual LIO terms, the definition 
for return and (>*=) are trivial. The former simply reduces to a monadic value 
by wrapping the term with the LIO TCB constructor, while the latter evaluates 
the left-hand term and supplies the result to the right-hand term, as usual. 


B Attack on naive flow-sensitive references 


leakRef :: Ref FS Bool LIO Bool 
leakRef href = do 

Iref <— newRef L True 
tmp <— newRef L False 
toLabeled H $ do h <— readRef href 

when h $ writeRef tmp True 
toLabeled H $ do t <— readRef tmp 

when (-1 t) $ writeRef Iref False 

readRef Iref 


Fig. 20: An attack in LIO with naive flow-sensitive reference extension without 

labelOf. 


As in the attack of Figure [7] the leakRef of Figure EOl can be used to leak the 
value stored in a H reference href , while keeping the current label L, without 
using labelOf. Internally, the value is leaked into public reference Iref by lever¬ 
aging the fact that, based on a secret value, the label of a public reference (tmp) 
can be changed (or not). In the first toLabeled block, if h = True, then the 
label of tmp is raised to H and its value is set to True. In the second toLabeled 
block, we read tmp , which may raise the current label to H if the secret is True 
(and thus tmp was upgraded). Indeed, if the secret is True (and thus t = True) 
we leave the public reference intact: True. However, if the secret is False , the 
tmp reference is not modified in the first toLabeled block and thus when read¬ 
ing it in the second toLabeled block, the current label remains L, and since 
t = False, we write False into the public reference. In both cases the value stored 
in Iref corresponds to that of href, yet leaving the current label and the label of 
Iref intact (L). 


C Embedding Theorem 

In this section we prove that the embedding from A^'° s into A^ 10 preserves seman¬ 
tics. 

We will use the following lemma for single A)'° s steps: 


Lemma 2 (Single-step embedding). Let t be a well-typed term in A"° s . Then 
if (E\t) — > (E'\t'), then there is a configuration Y such that ([L'] PI |p]^') —>* 
Y and ([r , ] FI |[i , ]K) —>•* Y, i.e. ([A7] FI |[<]^) and ([r'] FI |[f']J[) are /3-equivalent. 

Proof. Case analysis on the next redex in t. Most cases show a stronger version 
of the lemma, i.e. that (E\t) —>■ (E'\t') implies ([L'J FI |p]^) —>* ([L''] FI |[f']^). 
Case E [newRef FS l t\. 

We have (JC|E [newRef FS l t]) — >• (17'IE [return (Ref™ a)]), where 
S' = E [/z FS i->- E./j, fs [a i->- Lb TCB E.l cm (Lb™ l f)]], and we know that 
y 1 r I 

- s — / • t, cur _ 1 • 

Let Ei = [L’]fi. We argue 
(^i|[E [newRef FS l 

—* (r(|([E]^) [do l cnl t- getLabel; return ( wrap (Ref™ l CUI a))]) 

( E[ = E\ [p, FI i->- Ei./i f1 [i n- Lb TCB l t]]) 

—^ (£f|([E]£) [return ( wrap (Ref™ l cm a))]) 

(E" = Ei [/i FI n- Ei.fi FI [i t-> Lb TCB l f; 

a Lb TCB l CUI (Ref™ /?)]]) 


We now have to check that [return (Ref™ a)]^ = return (wrap (Ref™ l cur 
and lE'j Fl = E ", which follow directly from the definition of [-] F i for references 
and states. 

Case E [readRef FS (Ref™ a)]. 

We have (U|E [readRef FS (Ref™ a)]) —> (I7|E [unlabel ( Lb TCB (l U 
l') t)]), where E.p F s (a) = Lb TCB l ( Lb TCB l't). 

Let Ei = [I7] PI . We argue 


{^IIE [readR e f FS (Ref™ a)]]£) 

(Xd|([E]£) [readRef FI ({Ref™ a]| FI ) readRef n ]) 

(IfiKJE]];^) [unlabel (Ei.p F1 (a)) »= readRef FI ]) 
(iJ[|([E]^) [return (Ref™ V i ) »= readRef FI ]) 

(E'i = Ei [Z C ur Ei.l cur U /]) 

<^I([E] P ^) [readRef PI (Ref™ l' *)]> 

<^il(I E ln) [unlabel (E(.n F1 (*))]) 

(£" l(I E l£) [return f]) 

(E'{ = E[ [Z cur ^ r[./ cur U l']) 


Now if we consider ([Z'J FI |[E [unlabel ( Lb TCB (l U V) f)]] FI ), we have 

<[£] PI |[E [unlabel (Lb™ (l U V) f)]] FI ) 

—t (r 2 |([E]|[) [return t] 

(E2 = E2 [^cur ^ ([A 7 ] FI )./ cur U l U r])} 


Note that E".l CUI = ([rj FI )d cur U l U l' = E 2 .l c ur- 
Case E [writeRef FS (Ref™ a) t]. 


We have (17|E [writeRef FS (Ref™ a) t ]) — > (17'|E [return ()]), where 
Z> FS (a) = Lb TCB l (Lb™ l' v ), S' = E [^ FS ^ S.fx FS [a h- Lb TCB l ( Lb TCB l' «)]], 
and we know that S.l CUT C I Hi 1 . 

Let Si = [17] FI . Then there exists a function /i such that: 

(ri|[E [upgrade FS (Ref£ B a) /']][£} 

—> (X’lKHE]^) [toLabeled (Si.l CUI U l) (/x Si.l CUI )]) 

We now step through the evaluation of (Si\fi Si.l cur ), as follows: 


; writeRef FI i t) 


(Sl\^L Sl.l cnT ) 

—(^17i | doif- readRefj^g^TCB 
—> (17(|writeRef FI i t ) 

(S( = Si [Z cur H > Si.l CUI U l ]) 

—(17"|return ()) 

(S’l = S[ [ii FI ^ S( ./x PI [* H- Lb™ l• f]]) 

Finally, this allows us to conclude (from the rule for toLabeled), that 

(i7i|([E]j^) [toLabeled (Ei.l CUI U l ) (fi 17ii cur )[) 

—» (^ 2 |([E]^) [return ()]) 

where S -2 = (Si.l CUI , 17"./z FI ). Now we can check that |17'] F i = S 2 from the 
definition of [-] F i for states. 

Case E [upgrade FS (Ref™ a) l']. 

We have (17|E [upgrade FS (Ref™ a) l']) —> (I7'|E [return ()]), where 
S./j, fs (a) = Lb™ l (Lb™ l" v), S' = S [fx FS ^ 17.^ FS [a ^ Lb™ l (Lb™ (l U 
l" U ?')«)]], and we know that S.l CUI C l. 

Let Si = [I7] fi . Then there exists a function /r such that: 

(F7i|[E [upgrade FS (Ref™ a) /']]£) 

—► <£i|([E]£) [toLabeled (Ei.l cu r U l) (/j, Si.l CUT )}) 

We now step through the evaluation of (Si\fx 17i./ cur ), as follows: 

{Sl\n Si ./ C ur) 

— (Si\ doif- readRefj fle ^TCB a j^; Ic getLabel;...) 

—> (17(| do Ic <— getLabel; n •<— newRefpi (Ic U (l' U l )) _L;...) 

(17( = Si [/ cm - 1 —> Si.l CUI U l ]) 

—> (17(| donf- newRef FI (Ic U (V U /)) T; copyRef i n;...) 

—> (17"| do copyRef i n;writeRef FI ({Ref™ aJ FI ) n) 

(17" = 17( [/x FI n- S(./j, F1 [n 1 ^ Lb™ (Ic U (l' U /)) _L] ]) 

—*• (17("|writeRef FI (J Ref™ a] FI ) n) 

(S'" = 17" [/x FI ^ S".fjL F i [n Lb™ (Ic U (l' U /)) u]]) 

—* (17("|return ()) 

(17"" = 17(" [^ FI 17("./z fi [a H- Lb™ l (Ref™ (Ic U I' U I) n)}]) 


Finally, this allows us to conclude (from the rule for toLabeled), that 


<A|(P5]^) [toLabeled V (p A7 1 .Z cur )]> 
—> (^ 2 |([E]^) [return ()]) 


where JC 2 = (J7i.Z cur , P pi)- Now we can check that [17] F i = S 2 from the 

definition of [-] F i for states. 

Case E [downgrade FS (Ref™ a) l'). 

We have (I 7 |E [downgrade FS (Ref™ a) l']) — > (A7'|E [return ()]), 
where A 7 ./r FS (a) = Lb TCB l (Lb TCB l" v), S' = S [// FS i-> S./j, Fs [a 

Lb TCB l (Lb TCB (l U l" n Z') _L) ] ], and we know that S.l CUI C l. 

Let Si = [A7] fi . Then there exists a function /r such that: 

(I7i|[E [downgrade^ (Ref™ a) Z']]£> 

—> (I7i|([E]£) [toLabeled (SlI cui U l) (n S ,.^ r )]} 

We now step through the evaluation of (S\\n Si.l cur ), as follows: 


(Si\[iSi 

■^cur) 

(I7i| do i •<— readRef[ fie jTCB 0 j^; Ic •<— getlabel ;...) 

(S (| do Ic getLabel; n •<— newRef F i (Ic U (l' n Z))_L;...) 

(S[ = S\ [Z cur 1 —> Si.l cur U l ]) 

(I7(| donf- newRef FI (Ic U (V n /)) T;writeRef FI ([i?e/ F g B a] FI ) n) 
(A7"|writeRef FI ({Ref™ a] FI ) n) 

(S'{ = S'i [/i FI S[.fi F1 [n Lb TCB (Ic U (V n l)) J_]]) 

(A7"'|return ()} 


Finally, this allows us to conclude (from the rule for toLabeled), that 

(J7i.|([E]£) [toLabeled V ( M A7 1 .Z cur )]> 

—► (^|([E]K) [return ()]) 

where S 2 = (Si.l CUT , A7"'./z FI ). Now we can check that [A7'] FI = A7 2 from the 
definition of [-] F i for states. 

Now we can state the main theorem of this section. 

Theorem. [Embedding X L f FS in A^ 10 ] Let t be a well-typed term in A^° s . Then 
if (S\t) —(A7», we have ([A7] PI |[f]£) —<[A7 '] fi |[i;]^), and if (S\t) —s>* 
<^lt>, then ([A7 ] fi |M f ^) —►* <[A7'] FI |fi). 

Proof. By induction on the number of steps in (A7|t) — (S'\v), using Lemma[H 
and uniqueness of normal forms in A^ 10 . 


